home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960715-19961006 / 000080_news@columbia.edu _Sat Jul 27 03:58:15 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  8KB
  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id DAA03247 for <kermit.misc@watsun.cc.columbia.edu>; Sat, 27 Jul 1996 03:58:14 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id DAA20893 for kermit.misc@watsun; Sat, 27 Jul 1996 03:58:14 -0400 (EDT)
  4. Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!agate!info.ucla.edu!newsfeed.internetmci.com!in2.uu.net!brighton.openmarket.com!decwrl!nntp.crl.com!nntp.crl.com!croten
  5. From: croten@crl.crl.com (Charles Roten)
  6. Newsgroups: comp.protocols.kermit.misc,comp.dcom.modems
  7. Subject: Re: Problem getting 28800 bps in C-Kermit 5A(190) on a v.34 internal
  8. Followup-To: comp.protocols.kermit.misc,comp.dcom.modems
  9. Date: 27 Jul 1996 07:54:54 GMT
  10. Organization: Widgets, Inc.
  11. Lines: 139
  12. Message-ID: <CROTEN.96Jul27005455@crl.crl.com>
  13. References: <CROTEN.96Jul24005129@crl.crl.com> <4t63nh$imc@samba.rahul.net>
  14. NNTP-Posting-Host: crl.com
  15. In-reply-to: Clarence Dold's message of 24 Jul 1996 21:14:25 GMT
  16. Xref: news.columbia.edu comp.protocols.kermit.misc:5653 comp.dcom.modems:145769
  17.  
  18. Sorry, Clarence .. I added ',comp.dcom.modems' to the '^Followup-To: ' and 
  19. '^Newsgroups: ' lines again, due to the presence of some modem-chipset 
  20. related issues.  Since _both_ you _and_ Frank Da Cruz warned me about the 
  21. "Rockwell RPI" chipset problems, I decided to take you _both_ seriously 
  22. about this issue.  Though I still am not sure whether my modem has this 
  23. problem or not .. and indeed had never heard of it until your responses to 
  24. my earlier post.  
  25.  
  26. BTW, are there any diagnostics for this problem, other than the one Clarence 
  27. Dold alludes to below ??  I really do not know what to search for in the 
  28. rather scanty manual .. or what tests to make from the connected-state 
  29. command line.  
  30.  
  31. In article <4t63nh$imc@samba.rahul.net> Clarence Dold <dold@rahul.net> 
  32. writes:
  33.  
  34. >Charles Roten (croten@crl.crl.com) wrote:
  35. >: Yeah, I set the compile-time flag according to the file ckccfg.doc, so my 
  36. >: (SunOS) make looked like the following:  
  37.  
  38. >:     make sunos4 "KFLAGS=-DBPS_28K"
  39.  
  40. >SunOS already supports all of the possible speeds with the default Makefile.
  41. >You aren't going to add the strays like 28.8, or 14.4, no matter what you do.
  42. >(Not that you want to anyway.  You want a comm speed higher than your connect
  43. >speed).
  44.  
  45. >: I _did_ hack the Makefile to support fullscreen display with "-DCK_CURSES".  
  46. >: I also set "-DCK_WREFRESH" and "-DCK_PCT_BAR" .. all of which seem to do 
  47. >: remarkably little to change C-Kermit's rather uninformative behavior when 
  48. >: doing downloads.  
  49.  
  50. BTW, Frank Da Cruz _seems_ to imply _none_ of these mods are neccessary in 
  51. order to enable "fullscreen" display on a SunOS 4 box.  Maybe I went off 
  52. on an unneccessary tangent here ??  
  53.  
  54. >You also need to set
  55. >set file display fullscreen
  56. >either at the prompt, or in your .kermrc.
  57. >It supposedly slows down the transfer a bit, but the filling bar is nice.
  58.  
  59. Yeah .. I figured that one out after I posted .. sorry.  
  60.  
  61. But there _does_ seem to be a problem here, perhaps with interaction with 
  62. the antique windowing system (Sunview) my box uses.  _Any_ interaction 
  63. between any ovelapping window _or_ Sunview itself (such as closing the 
  64. window in which I use C-Kermit) and the "vttool" vt100 emulation window I am 
  65. (now) using as a C-Kermit terminal emulation front end can "freeze" Suntools 
  66. _totally_ for minutes to hours.  The only way of breaking out _by_ _choice_ 
  67. seems to be a system reboot.  Ugly.  
  68.  
  69. The only way to be safe seems to leave the "vt100" window open .. and then 
  70. _neither_ attempt to close it _nor_ manipulate any _other_ window across the 
  71. output panel.  
  72.  
  73. I have yet to test this with X11R5pl26.  
  74.  
  75. >: I _can_ set the speed to 38400 .. but max throughput indicates a solid 
  76. >: connection at _half_ that speed, 19200.  I _cannot_ seem to access 
  77. >[...]
  78. >: BTW, the system is an elderly Sun 386i, with a generic "Best Data" 
  79. >: "Smart One" (tm) 2834F Rockwell chipset v.34 internal modem.  
  80.  
  81. >A connection speed of 19200 sounds like a modem limitation.
  82. >Some "SmartOne" modems are Rockwell RPI, only fully usable with a special
  83. >software driver, usually under Windows.
  84. >Without this driver, they limit to 19200, and have no error correction, which
  85. >makes 19200 almost impossible.
  86.  
  87. Hmm .. no problem seen so far with 19200 .. except an apparent inability to 
  88. get above that throughput except fleetingly and temporarily during downloads 
  89. where _overall_ efficiency is rated by "stat" right at 50% (or a hair under) 
  90. for a _38400_ _bps_ connection.  I would expect 60-66% if I were receiving 
  91. at 28800 bps, of course.  
  92.  
  93. >Do you get a "CONNECT xxx00, LAP-M" or something like that?
  94.  
  95. Nope .. just "CONNECT 38400".  No ", LAP-M" suffix at all.  
  96.  
  97. The only place I see the "LAPM" string mentioned in my manual at all is in 
  98. the table of AT result codes, where result code 77, "PROTOCOL:LAPM", is 
  99. said to mean "v.42 LAP-M error correction".  I have _never_ come across the 
  100. "PROTOCOL:LAPM" message in any connection made with this beast.  
  101.  
  102. Included for your perusal is my (modified) .kermrc file.  
  103.  
  104. set line /dev/ttym1
  105. set incomplete keep
  106. set flow rts/cts
  107. set speed 38400
  108. set dial speed-matching off    <<<<---    _This_ line was _just_ _now_ added, 
  109.                     and _has_ _not_ _been_ _tested_ 
  110.                     _yet_.  If it works .. thanks, 
  111.                     Clarence.  
  112. set parity none
  113. set send packet-length 9000
  114. set receive packet-length 9000
  115. set window 1
  116. set file type binary
  117. set block 3
  118. set file display fullscreen
  119. set modem-dialer hayes
  120. set file names literal
  121. set wildcard-expansion shell
  122. set prompt vulcan>
  123.  
  124. Another problem I get from this combination of C-Kermit, terminal emulator, 
  125. and windowing system on my box is the (quite sudden) interruption of a file 
  126. transmission with the "too many NAKs" complaint from C-Kermit.  
  127.  
  128. Could this be an artifact of the fact that these file transmissions are 
  129. from a host in California (crl.com) which mounts C-kermit, _through_ _a_ 
  130. _telnet_ _connection_ _from_ _an_ _intermediate_ _host_ (a local Seattle-
  131. based ISP .. crl.com has no Seattle POP), to my local UNIX box ?  
  132. Yeah, I know .. a wierd way to do things ..  
  133.  
  134. Owing to the fact that I am not _sure_ of binary file transmission accuracy 
  135. in this "relayed" mode, I uuencode any file which even I _suspect_ of 
  136. containing  non-printable characters.  Then, when the "too many NAKs" bug 
  137. shuts me down, I can use UNIX "split", fore and aft, on the (uuencoded) file, 
  138. throwing away the last line or two on the receiving box and the lines before 
  139. that on the one sending.  Then I retransmit the remainder, and concatenate 
  140. the two partial files together at my destination.  Truly a disgusting hack.  
  141. Sigh.  
  142.  
  143. I'll try out the effect of 'set dial speed-matching off' in my .kermrc later 
  144. this evening.  Thanks.  I just hope it helps throughput, but I don't hold out 
  145. much hope of it assisting the fragility of Sunview in the presence of an 
  146. ongoing C-Kermit download in a vttool window.  
  147.  
  148. Perhaps (in respose to Frank da Cruz' earlier remarks) I'll try a generic 
  149. make with a non-tweaked Makefile, once I have (hopefully) nailed down the 
  150. throughput issue with the extra line in my .kermrc.  Since the extra 
  151. '-DCK_CURSES .. (etc.)' strings added to the link-edit lines of the Makefile 
  152. do not reportedly have any impact on the curses features or the "fullscreen" 
  153. display option one way or the other.  
  154.  
  155. [Clarence's .sig deleted]
  156.